Shareware Super Platinum 8

home *** CD-ROM | disk | FTP | other *** search

/ Shareware Super Platinum 8 / Shareware Super Platinum 8.iso / mac / ARCHIVE / PKBACKUP.ZIP;1 / PKBACKUP.DOC < prev

Wrap

Text File | 1994-04-25 | 21.1 KB | 507 lines

---------------------------------------------------------------- -- PKBACKUP.DOC for PKBACKUP.BAT version 1.0 -- 24 April 1994 -- ---- A Public Domain backup utility using PKZIP version 2.x ---- ---------------------------------------------------------------- 0. Table of contents. I. Introduction. II. Syntax. III. Use. A. How often to back up. B. How much to back up. C. How many diskettes to use. D. The backup pattern. IV. Recovering from file loss. A. Single file recovery. B. Total recovery. C. Problems and solutions. V. Environment and operation. VI. Modifying PKBACKUP. VII. Further suggested reading. VIII.Disclaimer, author, and credits. I. Introduction. PKZIP 2.x has been enhanced over PKZIP 1.1 to include a feature called "disk spanning," by which a single ZIP may be created on several floppies. This feature might be called a "poor man's" backup. However, even poor men (or women) prefer to avoid command lines with lots of switches. Therefore I have written PKBACKUP.BAT, a simple, easy to use and modify backup utility which takes care of the piddling details and attempts both to enable and encourage responsible data protection. PKBACKUP is designed to be an inexpensive (free if you already own PKZIP 2.x) Public Domain direct replacement for the MS-DOS BACKUP utility, with similar syntax. Enhanced features include fewer diskettes required to perform a backup, enhanced error detection, simpler syntax, and (in my opinion) easier recovery procedures with more options. This document describes PKBACKUP and its use. It also discusses backup strategy and data recovery using worked examples to illustrate key concepts. II. Syntax. PKBACKUP.BAT is patterned after the MS-DOS backup command. The command syntax is: PKBACKUP SOURCE DESTINATION [/SWITCH] where SOURCE is the drive to be backed up (*without* the colon, ex: 'C', not 'C:'), DESTINATION is the drive to be backed up onto (again, *without* the colon), and the optional SWITCH indicates what kind of backup to perform. DESTINATION must be a removable drive (read: floppy). There are three kinds of backups. The first is a total or FULL backup. This backup backs up all files on the source drive, as specified in PKZIP.CFG or the program's defaults, and then resets the archive bit on all files backed up. (Normally, PKZIP skips any files with Hidden or System attributes set.) Thus, the command: PKBACKUP C A /F would correspond to the MS-DOS commands: VERIFY ON BACKUP C:\*.* A: /S /F The second backup is an incremental backup or WEEKLY backup. This backup backs up all files modified since the latest FULL or WEEKLY backup (whichever was performed most recently) and then resets the archive bit on all files backed up. Thus, the command: PKBACKUP C A /W would correspond to the MS-DOS commands: VERIFY ON BACKUP C:\*.* A: /S /M /F The third backup is a DAILY backup. Like the WEEKLY backup, this backup backs up all files modified since the latest FULL or WEEKLY backup (whichever was performed most recently), however this backup does not reset archive bits on any files backed up. Thus, the command: PKBACKUP C A /D or PKBACKUP C A (the two commands are equivalent) would correspond to the MS-DOS command(s): FORMAT A: XCOPY C:\*.* A: /S /A /V (assuming all files to be backed up would fit on a single floppy.) After each of the backups completes, PKBACKUP performs an optional verify pass on the backup set. III. Use. A. How often to back up. A fundamental question of data protection is: "How often should I perform backups on my system?" The long answer is that you should back up frequently enough to recover quickly and completely with a minimum of re-entry should data loss of any sort occur. However, there are a couple of relative terms in the long answer, open to interpretation, confusion, and perhaps disaster, so go with the short answer: "Every time you use it." If you are entering data, downloading files, writing letters, or sometimes just playing games, the data files on your system change. You should establish a practice of backing up before shutting off the system for the day. For purposes of discussion, we will assume that the computer is used daily. B. How much to back up. If a backup requires daily 20 diskettes and an hour of your time, you will not do it. An "ideal" backup might require one minute and one diskette, so PKBACKUP was written to try to approach that "ideal." In the scheme presented below, a "full" or total system backup would be performed once every 28 days. Thereafter (assuming normal use), much smaller, quicker, partial backups would suffice. In this scheme, there are 10 separate backup sets. One set, labeled "F1", would be large enough to perform a FULL backup, and nine smaller sets of the same size, labeled "W1" through "W3" and "D1" through "D6" for WEEKLY and DAILY sets, respectively. C. How many diskettes to use. The FULL set would require (assuming a common file mix) approximately the number of diskettes which can be determined by this formula: number_of_diskettes = (FS / (CR * MS)) (rounded up) where: FS (File Size) is the number of bytes to back up (which can be determined by using MS-DOS CHKDSK) CR (Compression Ratio) is how well PKZIP performs compressing files. Depending on you file mix, this can vary between 1.0 (the worst possible) to 1.5 (poor) to 2.0 (excellent) or higher. A value of 1.7 is typical. When in doubt, use that. MS (Media Size) is the number of usable bytes on a floppy. The figure can be rounded to simplify arithmetic. (Remember this is an approximate calculation.) Use the table below (Table 1): Table 1: Approximate file bytes on common media. Media size Recording method Usable bytes ---------- ---------------- ------------ 3-1/2" DSDD 720,000 3-1/2" DSHD 1,440,000 5-1/4" DSDD 360,000 5-1/4" DSHD 1,200,000 Suppose you have a 104 MB partition as drive C: and MS-DOS CHKDSK indicates you are using 55,000,000 bytes (FS=55,000,000), and that your floppy drive A: is a high density 5-1/4" drive (and that you will be using high density floppies (MS=1,200,000). Applying the formula with a 1.7 compression ration (assuming a typical file mix -- CR=1.7): number_of_diskettes = (55,000,000 / (1.7 * 1,200,000)) (rounded up) = 26.96 (rounded up) = 27 A WEEKLY or DAILY set is harder to estimate, since it depends on the number and size of files modified. Start by assuming each set requires two diskettes and be prepared to revise upwards. Using these assumptions, the number of diskettes to buy initially for this example is shown in Table 2: Table 2: Diskettes required for backup sets (worked example). Backup type Sets needed Diskettes/set Total diskettes ----------- ----------- ------------- --------------- FULL 1 * 27 = 27 WEEKLY 3 * 2 = 6 DAILY 6 * 2 = 12 ----- -- ---- TOTAL 10 45 If you buy your diskettes in lots of ten, hold your nose and buy 50. Remember, this is *still* better than MS-DOS BACKUP which would require about 46 or 47 diskettes just for the FULL backup alone. WARNING: If you are using low density diskettes in a high density drive (ex: 360 KB DSDD floppies in a 1.2 MB HD drive) then YOU MUST FORMAT THEM LOW DENSITY BEFORE USING PKBACKUP. Otherwise, PKZIP will format them high density. D. The backup pattern. Why these three kinds of backups? PKBACKUP was written with the following scheme in mind. Initially, you would perform a FULL backup on a disk. This would back up all files, and form a basis for all further backups in the series. We will call this "day zero." For the next 6 days, you would perform DAILY backups, using backup sets D1 through D6. On day seven, you would perform a WEEKLY backup using backup set W1. On days eight through thirteen you would do DAILY backups, reusing backup sets D1 through D6. On day fourteen you would perform a WEEKLY backup using backup set W2. On days fifteen through twenty you would perform DAILY backups again on D1 through D6. On day twenty-one you would perform a WEEKLY backup on backup set W3. Finally, for days twenty-two through twenty-seven you would do DAILY backups again on D1 through D6. Day 28 would be day zero of the next cycle, and the process would repeat. Graphically, this might be represented as shown in Table 3 (below): Table 3: Sequence of backups in a 28-day backup scheme. Type Set Day ---- --- --- FULL F1 day 0 DAILY D1-6 days 1 to 6 WEEKLY W1 day 7 DAILY D1-6 days 8 to 13 WEEKLY W2 day 14 DAILY D1-6 days 15 to 20 WEEKLY W3 day 21 DAILY D1-6 days 22 to 27 This scheme has the following characteristics: It is always possible to restore files for the previous seven days, and before that, at one week intervals. Therefore, if you back up at the end of a day, and file loss occurs at noon on day 18 (before backup on that day), then the following backups would be available, as shown in Table 4 (below). Table 4: Backups available on day 18 in a 28 day backup scheme. Number Type Set Day performed ------ ---- --- ------------- 1 FULL F1 day 0 2 WEEKLY W1 day 7 3 DAILY D4 day 11 4 DAILY D5 day 12 5 DAILY D6 day 13 6 WEEKLY W2 day 14 7 DAILY D1 day 15 8 DAILY D2 day 16 9 DAILY D3 day 17 NOTE: The method described above can be adapted to work for other time frames just as easily. If backups are performed weekly, then 17 backup sets consisting of one FULL set, 12 monthly sets and 4 weekly sets will back up an entire year. Other schemes are possible. The important part is that there must be an initial FULL backup, followed by WEEKLY backups at specified intervals and DAILY backups between them. IV. Recovering from file loss. Sooner or later, it will be necessary to restore one or more files from backup. Whether from accidental deletion of a single file (oops) all the way up to catastrophic disk failure (ARGH! *SOB*), PKBACKUP creates backup sets capable of recovery. To illustrate recovery methods, we will continue use of the 28 day backup scheme described earlier and examine recovery techniques used if data loss occurred after backup on day 17. (See section III D for details). (Remember that for this discussion drive C: is backed up onto drive A:) NOTE: Before attempting recovery of any sort, you should be familiar with PKUNZIP. The more you know about this utility, the more options for recovery you will have. See Section VII for suggested reading. A. Single file recovery. Suppose a single file named C:\GONE\BYE.BYE was accidently deleted at noon on the eighteenth day as described in Section III D. Table 4 (above) shows the nine backups available. BYE.BYE should be on at least one of them (see IV C -- Problems and Solutions, below), and might be on several or all, depending on whether the file was modified. In this case we would want the youngest (most recently modified) copy. Therefore we would start with the latest backup, backup number 9 (performed on day 17), and search the backups in reverse chronological order. To search a backup for a file, place the LAST disk of the set (yes, you heard me correctly!) in the floppy drive and (assuming that it is drive A:) type in the following command: PKUNZIP -v a:*.zip bye.bye (If you forget, and put the first floppy of the set in the drive, PKUNZIP will prompt you to put the last floppy of the set in the drive. All you will have lost is some time.) It is not necessary to give the full path of the file, the true name of the ZIP file, or even the full name of the file itself, since wildcards can be used in the filename. Any file matching a specification will be displayed along with "directory-like" information such as size, attributes, date and time of creation/last update, full path name, and a few other fields which will not be important to the restoration process. If the file is not in the backup set, PKUNZIP will issue a warning. If several files match the specification, they will all be displayed. It is your responsibility to determine which, if any, is the file you want. If the file is not found in backup 9, continue the search using backup 8, and so on. Once the right backup set has been determined, restoring a single file can be done using the following command, assuming C: is the backup drive and A: is the floppy drive. PKUNZIP -d -o- a:*.zip filename.ext c:\ so in our example we would type: PKUNZIP -d -o- a:*.zip BYE.BYE c:\ If more than one file matches a specification, all files will be restored. If a file already exists by the same name, PKUNZIP will skip the file. (This would almost certainly mean that the specification was incorrect or there was more than one file with that name in the backup.) If no files could be restored, PKUNZIP would issue a warning. B. Total recovery. Suppose the very worst has happened, and the disk is lost. After replacing or reformatting the disk and installing a minimum amount of the operating system, if necessary (you did have a rescue disk of some kind around, didn't you?) we must restore the latest DAILY backup, then all WEEKLY backups in reverse chronological order, then finally the FULL backup. In our worked example, assuming loss on day 18, we would restore backups 9, 6, 2, and 1 in that order. (See table 4.) Assuming that drive C: was lost, and that enough of MS-DOS has been installed (and in the SAME place as before), we could enter the following command: PKUNZIP -o- -d a:*.zip c:\ for each backup set (even from another drive) and only those files which had not yet been restored would be written to the hard drive. C. Problems and solutions. PKBACKUP, like MS-DOS BACKUP, requires a file's Archive bit to be set before it will back it up in a WEEKLY or DAILY backup. Therefore, if one resets the Archive bit with the MS-DOS ATTRIB command, performs a regular MS-DOS BACKUP, renames an already backed up file (which will not affect the Archive bit), or anything else which messes with the Archive bit for a file, then that file will not be backed up, or possibly it may be backed up though it does not need to be. If this represents a problem for you, then maybe you ought to be using a different method for performing backups. On the other hand, with a little care and attention to detail this should not be a serious problem. Don't use both MS-DOS BACKUP and PKBACKUP. Don't use XCOPY's /M switch. Don't use ATTRIB to clear the Attribute bit of a file unless you know EXACTLY what you are doing. Instead of RENaming a file, COPY it, then DELete the original. (Be aware that the file with the original name may exist on a backup, which might cause a problem if a total recovery is necessary.) Remember that a file created and deleted between backups cannot be recovered using techniques described here. A different problem is that PKBACKUP may back up certain files not desired or may skip other files. There are frequently files or directories on the root directory which are useless for backup purposes since they relate to file undeletion, format recovery, antiviral protection, or some other utility purpose. If that is the case, then PKBACKUP can be modified to exclude such files. Another possible problem is that, by default PKZIP (and therefore PKBACKUP) does not back up any file with the Hidden or System file attributes set. This is probably the way you want it anyway, but if necessary PKBACKUP can be modified to back these up as well. V. Environment and operation. PKBACKUP is designed to run under MS-DOS 3.0 (preferably MS-DOS 3.3) or later. It uses PKZIP 2.0x to perform backups. (I have done all testing using PKZIP 2.04g, registered version.) No other programs are used -- all functions are performed by batch commands. PKBACKUP has been tested under PC-DOS 3.3 on an IBM PC/AT with 640 KB RAM memory and under MS-DOS 5.0 on a 386 clone with 4 MB RAM memory with QEMM 7.03, EMS, XMS, and DPMI support. Your mileage may vary, but it worked fine for me. PKBACKUP tries to be tolerant about uppercase/lowercase, and provides default operation if omitted. It does careful checking as to legal SOURCE and DESTINATION drives, and provides an informative usage message if a syntax violation is discovered. If a runtime error occurs, PKBACKUP attempts to diagnose the problem and present an appropriate error message. NOTES: PKBACKUP will switch to the drive which is being backed up, uses Maximum compression, MS-DOS VERIFY ON, and uses PKZIP or system defaults to determine memory usage. It will span disks, if necessary, and always starts out by formatting each floppy it uses. It does a quick format, if possible. The ZIP file produced has the following name on all floppies in a backup set: Type Name ---- ---- FULL full_X.zip WEEKLY week_X.zip DAILY daily_X.zip where X is the SOURCE drive from the invocation. VI. Modifying PKBACKUP. PKBACKUP has been written with the certainty of change as a design criteria. Many parameters may be altered by REM'ing out or unREM'ing sections of code already included in the batch file. It is a simple matter to change legal source or destination drives, or default operation. The use of the PKTMP environmental variable is selectable, as is the MS-DOS VERIFY option. There is only one file, so all portions of the batch can be printed as one file. I didn't try to do *anything* tricky. One area of possible improvement for PKBACKUP is the compression method. I chose Maximum compression to reduce the number of diskettes. If you have a slow machine (I have a 8 mhz AT), then it may be worth it to you to use a faster compression level and use more floppies. VII. Further suggested reading. If you are interested modifying PKBACKUP, or want to know more about concepts described in this document, I would suggest reading the "PKZIP 2 for DOS Manual" which is given with every registered copy of PKZIP 2.x. (Don't just use the shareware version, buy the real thing.) There is a section in the book called "Tutorial" which has a subsection "Storing and Rebuilding Directory Structures" which I recommend. Also, when in doubt, consult the help screens for PKZIP and PKUNZIP. VIII. Disclaimer, author, and credits. PKBACKUP.BAT and this file PKBACKUP.DOC are hereby released into the public domain. Use them, modify them, and/or abuse them as you see fit. If you wish, include them as part of a package you sell. (Please include this file if you are a gentleman, sir.) Naturally, I assume no liability for ANYTHING that goes wrong, either directly or indirectly, (ESPECIALLY if the code is modified). If you want a warranty, go to someone else. On the other hand, if you want to thank me (the author) I can be reached at the following address: Phil Hair 961 Reynolds Rd., #125 Toledo, OH 43615 Have fun. -- Phil PKZIP and PKUNZIP are registered trademarks of PKWARE, Inc. MS-DOS is a registered trademark of Microsoft Corporation. IBM, IBM PC/AT, and PC-DOS are registered trademarks of International Business Machines Corporation. QEMM is a registered trademark of Quarterdeck, Inc. The author is not associated with PKWARE, Inc. ---------------------------------------------------------------- ----------------------- END OF DOCUMENT ------------------------ ----------------------------------------------------------------